Industrial controllers are special-purpose computers utilized for controlling industrial processes, manufacturing equipment, and other factory automation, such as data collection or networked systems. Controllers often work in concert with other computer systems to form an environment whereby a majority of modern and automated manufacturing operations occur. These operations involve front-end processing of materials such as steel production to more intricate manufacturing processes such as automobile production that involves assembly of previously processed materials. Often such as in the case of automobiles, complex assemblies can be manufactured with high technology robotics assisting the industrial control process.
In many automated processes, including the basic production of commodities such as food, beverages, and pharmaceuticals, complex state logic is often designed and programmed by Systems Engineers or provided in some cases by automated equipment manufacturers. This logic is often programmed with common PLC ladder logic or higher level languages supported by Sequential Function Charts. Sequence logic can be employed for a plurality of tasks such as material movement and conveying operations, packaging operations, or as part of an assembly process itself, wherein various stages of an assembly are sequenced from stage to stage until a final assembly occurs. As can be appreciated, much planning and design is required to implement an automated production process that can involve hundreds of machines, computers, and program logic to facilitate proper operation of the respective sequences.
In some batch systems for automating production processes, current batch products can aggregate Units for production into Unit Classes, where a Unit Class defines the global common functionality of all Units that are members of the Unit Class. This allows for the construction of “class-based” recipes, built against a Unit Class or Classes. When building a class based recipe, a recipe author is generally limited to referencing only the functionality common to all instances of the Unit Class. This generally results in the class based recipe being able to run against all instances of the Unit Class. The “common functionality” that can be referenced across all members of a Unit Class by class based recipes are Recipe Phases and Unit Tag Classes. However, variations in the properties (attributes) of the individual reactors are great enough that the set of properties (attributes) that are common to all instances of the class are limited. Recipe Phases can be employed as “steps” inside of Unit Operation Sequential Function Charts (SFCs), for example. Unit Tag Classes can be referenced by Transition Expressions on Transitions inside of class based Unit Procedure and Unit Operation SFCs.
With respect to many applications however, the set of functionality common across all instances of a unit class may be so small as to not be useful. For example, a plant may have a large number of similar units that it considers to be reactors. Thus, the set of Recipe Phases and Unit Tag Classes that are supported across all instances of the reactor class may be so small as to not allow for the creation of useful class based recipe structures. However, there is likely to be significant commonality between some reactors that does not extend to the entire set of reactors. For example, some subset of reactors may contain agitators. Some other subset of reactors may contain temperature sensors. Thus, in some cases the current concept of Unit Class commonality only recognizes global commonality, wherein the user loses the benefit of being able build class based recipes that utilize subsets of commonality. Also, there may be attributes of a Unit, such as materials of construction, or temperature that make it acceptable, unacceptable, desirable, or undesirable for use with certain recipes.